tractorsfandomcom-20200215-history
Template talk:If pagename
The folleowing additional info about this template has been copied her from the original at wikipedia:Template_talk:If_pagename as the template documentation references to it. About ((if pagename)) A year ago I (David) and Dinoguy1000 discussed creation of this template and the related . Our old discussion is at Template talk:Main talk other#Basepage-subpage detection template and provides some insight in the thoughts behind this template. Some discussions on the talkpage of are also relevant. This template has fairly complex code, but it is efficient since most comparisons are done on empty strings. For instance its /testcases page has lots of examples, still its "NewPP limit report" is pretty low. (Those reports are inserted by the Wikipedia servers and can be found if you "view the source" of a generated page in your web browser. They show some data about how much server resources the templates on a page cost. It works on previews too, so no need to save a page to see the report.) If you are brave enough to read the code of this template, then you might want to know these things: Most of the parameters fed to this template are not processed when on a page. Thus you can feed many parameters, without much cost. Instead this template puts together the different possible parameter names for the current page and checks if any of those parameters are defined. If/when if finds one it returns the content of that parameter. Thus only the content of at most one parameter is processed. The parameter for matching with the full pagename of this talk page would be " }". That parameter can be built on any page like this: " |}}}". This template uses the parameter pipe-trick to detect empty but defined parameters. Like this: } }} : } }} When indenting a parameter like that we usually get horrible whitespace problems, but the " " fixes that since it strips away the whitespace. In an earlier version this template instead used ParserFunctions to do the same thing. Like this: }| } | } | Parameter 2 is undefined, do other work. }} : }| } | } | Parameter 2 is undefined, do other work. }} As can be seen, in this case using the parameter pipe-trick above is more efficient. However, if you don't just need to return the contents of the parameter but instead need to do some work on it, then you need to use the ParserFunctions approach. For comparison, here is the usual method where empty parameters are treated the same as undefined parameters: } | Parameter 2 has data | Parameter 2 is undefined or empty }} : } | Parameter 2 has data | Parameter 2 is undefined or empty }} But since we need this template to stop matching when it gets an empty (but defined) parameter we need to use one of the approaches above. --David Göthberg (talk) 5-10 November 2009 (I have updated this message several times.) :The comments below was copied here from my talk page. --David Göthberg (talk) 00:57, 11 November 2009 (UTC) :Just a drive-by comment: this template is insane. Insane in an "any sufficiently advanced technology is indistinguishable from magic" sort of way. That's an awesome piece of wikicode... again... :D [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 17:32, 7 November 2009 (UTC) ::Yep, using parameter logic has gone a bit out of style with the advent of parser functions (Aah, qif ...). It's a pity that it's limited to only the 4-6-8 char prefix matching, but it's probably enough, and anything else would destroy the switch-like elegance. Amalthea 21:48, 8 November 2009 (UTC) :::Haha, thanks Happy-melon and Amalthea. Yeah, it is kind of "insane" code. :::And yeah, it is a pity that we have to limit the number of lengths that the "prefix matching" can handle. We can add more but each length costs one line of code, and thus costs more resources to run. So using a handful of lengths like that probably is a good compromise. :::And by the way: is just the regular version of this template, since I am planning a deluxe version. Probably named . It will have the same additional features as has compared to . The "showall" function isn't important, but being able to feed the same data efficiently to several matching names is needed. :::--David Göthberg (talk) 00:31, 10 November 2009 (UTC) :End comments copied here from David's talk page. --David Göthberg (talk) 00:57, 11 November 2009 (UTC) ::Time for some attribution: I just realised that a part of this template, the "partial subpage name matching" (or "prefix matching" as Amalthea calls it), as in "/some*", was Amalthea's idea. He showed me some code doing that a week before I coded this template, although the way I implemented it here is quite different. Thanks Amalthea! ::Odd that someone tells you an idea, and then some days later you think it is your own idea. Thankfully our discussions remain on the talkpages to remind us! :)) The rest of the matching was invented by me and Dinoguy1000 a year ago, see top of this section. Unless of course we got the ideas from somewhere else and have forgotten about it... ::I notice that Amalthea (probably independently) had added some other related matching to his templates. So I guess the time was ripe for this kind of matching. ::--David Göthberg (talk) 02:43, 11 November 2009 (UTC) Pattern syntax When trying to explain for others what and do, I realised there might be a more clear syntax we could use. Currently these templates use patterns like this: Example 1 (as it is now): User:Example/ = Match on all subpages of "User:Example", but not "User:Example" itself. /something = /some* = But another way to express it could be: Example 2: User:Example/* = */something = */some* = The old syntax "User:Example/" feels confusing, for that one to use "User:Example/*" would perhaps be clearer? But using "*/something" feels unnecessary and "*/some*" looks a bit weird. So how does the below syntax feel? Example 3: User:Example/* = /something = /some* = I think I prefer example 3, but I am not sure. I would like some feedback from others on this. --David Göthberg (talk) 17:24, 15 November 2009 (UTC) *Hmm, that's an interesting question. I agree that an explicit wildcard character is much clearer; it's not a significant (or even noticeable) timewaster for 'power coders', and it makes the syntax significantly more intuitive for ordinary users. I would say that using the wildcard consistently is just as important as using it at all, so I would go with your second example. [[User:Happy-melon|'Happy']]‑[[User talk:Happy-melon|'melon']] 23:35, 15 November 2009 (UTC) *I can't decide. :) I'm torn between brevity, unambiguousness, and intuitiveness. Version 2 seems to be the most consistent and most readable one, but such syntax actually promises more than it can deliver. We can't process *talk:Example/* or *noticeboard/ or */foo/bar/* – in the end, the leading star is just decoration, and one still has to check which cases the template actually can match. If this template were a traditional one that received the switch conditions in parameter values I'd certainly be in favor of version 2, since once we have string parsing functions (I can dream, right?) it could seamlessly be extended to do proper wildcard matching. This one won't ever be able to do that (unless MediaWiki is extended to allow enumeration of parameter keys), so I probably favor fewer *s, i.e Version 1 or 3. Amalthea 00:05, 16 November 2009 (UTC) * Adding the wildcard, although strictly speaking completely incorrect, makes it understandable on a strong intuitive level. Debresser (talk) 16:43, 16 November 2009 (UTC) ::Thanks for the feedback guys. You bring up many good points. ::Meanwhile I have been thinking a bit more: ::When I write "on a /doc page" everyone seems to know what I mean, since Wikipedia template programmers are used to that notation. So I think adding a "*" in those cases will probably cause more confusion, since people are not used to see "on a */doc page" . ::While if I write "on the User:Example/ sub-pages", then I bet most users would be confused. Since we usually express it as "on the sub-pages of User:Example". So there we need the "*" in the syntax for this template. ::So I now strongly prefer example 3. And as second choice I prefer example 2. ::--David Göthberg (talk) 17:55, 16 November 2009 (UTC) * I know I'm a bit late to this party, but David asked me to swing by a few days ago and offer my thoughts. I think any thoughts I may have had have already been summed up by everyone else above me, so I'll skip the puffery and say that example 3 is the one I like the most. =) 「ダイノガイ 」 · Talk⇒Dinoguy1000 07:45, 19 November 2009 (UTC) A page and its subpages :Dinoguy1000 asked if these templates have some way to specify "a page and its subpages" in one single rule. But currently these templates don't have that. Currently we can only do this: | User:Example = x | User:Example/* = x :But Dinoguy1000 is right, we could have good use of such a syntax. And I could easily add that to these templates. So time for some brainstorming: The first syntax I can think of could look like this: | User:Example/+ = x :Any other suggestions or comments from anyone are most welcome. :--David Göthberg (talk) 11:35, 17 November 2009 (UTC) ::The only other reasonable syntax I can come up with offhand might be User:Example/@ = x, with @ standing for "all", but that is probably too obtuse for most people to find it memorable. I don't suppose there are any computer systems or programming languages which have syntax for similar cases, are there? (regular expressions have a syntax for "zero or more characters", which is similar in principle, but is used almost completely differently, I think) 「ダイノガイ 」 · Talk⇒Dinoguy1000 07:45, 19 November 2009 (UTC) :::Thanks for pointing out regular expression. So I checked the regular expressions article. It says "zero or more = *" and "one or more = +". Depending on how one interprets it we have either chosen the right ones, or we have reversed the order. But of course, as you stated, regular expressions use that in quite a different way from how we use it here. The good part is that they too have chosen the two symbols * and +. And I think + feels "inclusive", and it is easy to recognise, so it feels good. :::Anyway, I have implemented the /+ syntax and we now use it over at . :::--David Göthberg (talk) 13:34, 19 November 2009 (UTC) ::::Giving it more thought, I still can't think up any other possible alternative syntaxes for this functionality. but it's fine because the + actually does make a certain amount of sense. =) I'd still like to see parallels from programming languages and computer systems, but I think this is probably fine as-is now. 「ダイノガイ 」 · Talk⇒Dinoguy1000 23:13, 19 November 2009 (UTC)